When a TCP (Transmission Control Protocol) connection starts, a destination host receives a SYN (synchronize/start) packet from a source host and sends back a SYN ACK (synchronize acknowledge). The destination host normally then waits to receiver an ACK (acknowledge) of the SYN ACK before the connection is established. This is referred to as the TCP “three-way handshake.”
While waiting for the ACK to the SYN ACK, a connection queue of finite size on the destination host keeps track of connections waiting to be completed. This queue typically empties quickly since the ACK is expected to arrive a few milliseconds after the SYN ACK is sent.
A TCP SYN flood attack is a well known denial of service attack that exploits the TCP three-way handshake design by having an attacking source host generate TCP SYN packets with random source addresses toward a victim host. The victim destination host sends a SYN ACK back to the random source address and adds an entry to the connection queue, or otherwise allocates server resources. Since the SYN ACK is destined for an incorrect or non-existent host, the last part of the “three-way handshake” is never completed and the entry remains in the connection queue until a timer expires, typically, for example, for about one minute. By generating phony TCP SYN packets from random IP addresses at a rapid rate, it is possible to fill up the connection queue and deny TCP services (such as e-mail, file transfer, or WWW) to legitimate users. In most instances, there is no easy way to trace the originator of the attack because the IP address of the source is forged. The external manifestations of the problem may include inability to get e-mail, inability to accept connections to WWW or FTP services, or a large number of TCP connections on your host in the state SYN_RCVD.
A malicious client sending high volume of TCP SYN packets without sending the subsequent ACK packets can deplete server resources and severely impact the server's ability to serve its legitimate clients.
Newer operating systems or platforms implement various solutions to minimize the impact of TCP SYN flood attacks. The solutions include better resource management, and the use of a “SYN cookie”.
In an exemplary solution, instead of allocating server resource at the time of receiving a TCP SYN packet, the server sends back a SYN/ACK packet with a specially constructed sequence number known as a SYN cookie. When the server then receives an ACK packet in response to the SYN/ACK packet, the server recovers a SYN cookie from the ACK packet, and validates the recovered SYN cookie before further allocating server resources.
The effectiveness of a solution using a SYN cookie depends on the method with which the SYN cookie is constructed. However, existing solutions using a SYN cookie typically employ a hash function to construct the SYN cookie, which can lead to a high percentage of false validations of the SYN cookie, resulting in less than satisfactory protection again TCP SYN flood attack.
Therefore, there is a need for a better system and method for constructing and validating SYN cookies.